Some client devices may have network access, but their network access may be limited to a set of application services. Network operators may use policies to impose such limitations. In one example, a particular application service provider may sponsor network access of a client device. The client device may be limited to application services run by the application service provider on its server. In another example, a client device with network access may be part of a contract that allows for special charging or handling of data (e.g., bit rate or quality of service) associated with a given application service. For example, a client device may have a cellular subscription through a cellular provider and that cellular provider may wish to impose one or more restrictions on the client device. In one example, a corporation that is today known as a provider of social media, but not known as a cellular provider, may play a role as a cellular provider in the future. In this example, the client device may have a subscription with the corporation. As part of its subscription agreement, the client device may gain access to the Internet but may be restricted to use the social media site of the corporation to the exclusion of other social media sites. By way of another example, a client device may have a subscription with a provider of streaming media services. In this example, as part of an agreement, the client device may gain access to the Internet through various cellular providers (e.g., mobile network operators). However, access may be restricted by agreement (between the provider of streaming media services and the various cellular providers and/or the user of the client device) to use the site of the provider of media services for all streaming media services. By way of another example, for certain access point names (APNs), only certain traffic (e.g., control-plane signaling and/or user-plane messages) may be allowed to be sent from a client device based on a policy or subscription limitation.
Network policies may be instituted in connection with application services to ensure that a client device is not violating any agreements, is being provided access to agreed upon application services, and/or is being provided with an agreed upon level of service. A network may enforce such policies against uplink (UL) packets sent from a client device toward, for example, an application server on a packet data network (e.g., the Internet). A network may additionally enforce such policies against downlink (DL) packets sent from the application server toward the client device.
Today, policy enforcement for application services occurs at a gateway to a network. An example of such a gateway is a packet data network gateway (P-GW), which serves as a gateway between a core network (e.g., evolved packet core (EPC)) and a packet data network (PDN), such as the Internet. One problem exists in that policy enforcement (e.g., enforcement of service access policies) may require a P-GW to validate all UL and DL packets sent between a client device and application servers. Moreover, each UL packet and DL packet may need to be steered to its destination address via a particular bearer or data flow. A destination address may be comprised of two parts: a prefix part and a suffix part.
Network policies may be enforced by validation of UL and DL packets at the P-GW. Enforcement may ensure that a client device is only sending/receiving packets to/from an authorized application service. Validation may include verifying the destination address or the destination address and the port number of packets passing through the P-GW. Validation may additionally include verifying the source address of each packet. Verifying the source address of each packet may be useful for anti-spoofing (e.g., by preventing packets from unauthorized client devices from fooling a network by appearing to come from an authorized client device). Packet steering may be needed to ensure that an agreed upon quality of service (QoS) is achieved.
Current practices incur substantial overhead and add forwarding latency due to processing delay. The current practice is typically realized using packet inspection (e.g., deep packet inspection, shallow packet inspection) and traffic flow template (TFT) and service data flow (SDF) templates. The P-GW confirms that the packets conform to a TFT/SDF template defined for the service(s) by inspecting the headers of each packet.
FIG. 1 is a prior art illustration of a role of an SDF template 102 in detecting a downlink part of a service data flow 104 and mapping that part to bearers, such as the Internet Protocol-Connectivity Access Network (IP-CAN) bearers 106 shown. FIG. 1 is based on 3GPP technical specification (TS) 23.203, FIG. 6.4.
An SDF template 102 is created to validate and map downlink packets. However, use of the set of packet filters (see, e.g., packet filters a-f in the SDF template 102) requires the use of tables and table lookup procedures. Use of such tables and procedures affects efficiency in that the use requires memory storage space and processor resources to execute the procedures. Additionally, time resources are wasted in that each packet must be filtered through a plurality of filters before any given packet is applied to a filter that meets all of the requirements of the filter.
Using packet inspection and TFT/SDF templates at the P-GW (for either or both of uplink and downlink packets) is therefore problematic, for example, because their use incurs substantial overhead (e.g., processing and memory resources for memory lookup and pattern matching) and adds forwarding latency due to processing delay. Additionally, fine-grain policy control (e.g., per service) is difficult because additional policy control would incur additional overhead and processing delay because a packet would need to be tested against additional filtering rules realized by TFT/SDF templates. Furthermore, use of TFT/SDF templates is not scalable for sponsored connectivity. An increase in the number of sponsors of different services (perhaps thousands of services in the years to come) would mean an increase in the time needed to filter packets through a correspondingly increased number of TFT/SDF templates. This, again, would incur additional overhead and processing delay.
What is required is an alternative to supplement and/or enhance packet inspection and to improve efficiency in enforcement of uplink and downlink network policies.